Apple veut réduire la durée de validité des certificats, colère chez les administrateursCrédits : JJ Ying (Unsplash)

Apple veut réduire la durée de validité des certificats, colère chez les administrateurs

Pour votre bien

23

Apple veut réduire la durée de validité des certificats, colère chez les administrateursCrédits : JJ Ying (Unsplash)

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Apple propose de réduire la durée de validité des certificats de sécurité à 45 jours, contre 398 actuellement. Bien que la proposition ait été faite pour augmenter la sécurité générale, elle provoque la colère de très nombreux administrateurs système.

Les certificats sont un maillon essentiel de la chaine de sécurité. Ils servent à prouver, en théorie, que l’on est bien qui l’on prétend être. Ils sont là pour assurer l’identification d’une entité et sont à la base de la chaine de confiance sur Internet, encore aujourd’hui. Mais leurs problèmes sont multiples. Notamment, si un acteur malveillant arrive à s’emparer d’un certificat, il peut exploiter des failles potentielles pendant une durée prolongée.

Apple veut réduire la validité à 45 jours

C’est à cette durée que veut s’attaquer Apple. Notons d’emblée que ce n’est pas la première entreprise à proposer une telle réduction. Avant 2011, la validité d'un certificat pouvait ainsi porter sur un maximum de 8 ans. Au cours de la décennie suivante, la durée a été progressivement rabotée pour atteindre le maximal de 398 jours que l’on connait aujourd’hui. Cependant, Google avait déjà suggéré de la faire descendre à 90 jours.

Il reste 81% de l'article à découvrir. Abonnez-vous pour ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Commentaires (23)


J'ai du mal à voir comment Apple pourrait forcer la réduction de la durée de validité des certificats. La durée d'un certificat est à la discrétion de l'autorité de certification. En fait, le seul moyen possible serait qu'Apple retire de la liste des autorités de certification une autorité qui ne respecterait pas cette durée. Mais il faudrait alors que Google fasse de même avec Chrome.

Sinon, c'est oublié aussi qu'un certificat de sécurité peut avoir plusieurs objectifs. Le plus répandu aujourd'hui, la sécurisation du canal de communication. Mais il existe aussi des extensions, notamment le Extended Validation (EV) qui vise aussi à certifier le titulaire.

Par exemple, pour Next, cela signifierait que l'autorité de certificat à vérifier que le domaine next.ink est bien contrôlé par l'entité qui demande un certificat, mais que cette entité est bien celle qu'elle prétend être (Moji ou Next). Ce type de certificat est souvent plus cher (car nécessite de transmettre des documents).

Si un temps ces certificats "étendus" étaient clairement affichés par les navigateurs, ce n'est plus vraiment le cas aujourd'hui par les navigateurs les plus courants. C'était quand même bien pratique pour des sites sensibles comme celui des impôts de savoir qu'on était bien sur le site des impôts et pas sur un site de phishing.

Et des certificats EV de 45j, ça n'a pas vraiment de sens... surtout que la procédure de vérification peut prendre plusieurs semaines !
Apple, Google et tous les autres: Mozilla avec Firefox, Oracle avec Java... Sur ces 2 derniers, ils embarquent par défaut leur propre liste d'autorités de certification validées, en ignorant celle du système.

Pour le certificats EV, la vérification de l'entité peut décorrélé de l'émission du certificat. (3 ans par exemple pour la validation EV, et 45 jours pour le certificats)

XSBen

Apple, Google et tous les autres: Mozilla avec Firefox, Oracle avec Java... Sur ces 2 derniers, ils embarquent par défaut leur propre liste d'autorités de certification validées, en ignorant celle du système.

Pour le certificats EV, la vérification de l'entité peut décorrélé de l'émission du certificat. (3 ans par exemple pour la validation EV, et 45 jours pour le certificats)

Pour info, Firefox n'ignore plus les certificats systèmes aujourd'hui.
Pour le certificats EV, la vérification de l'entité peut décorrélé de l'émission du certificat. (3 ans par exemple pour la validation EV, et 45 jours pour le certificats)


Certes. Mais cela signifie aussi plus de manipulation du certificat, donc plus de risque qu'il fuite. Je ne suis pas certains que cela soit souhaitable. Il faudrait avoir un retour sur la balance bénéfice/risque.

fdorin

Pour info, Firefox n'ignore plus les certificats systèmes aujourd'hui.
Pour le certificats EV, la vérification de l'entité peut décorrélé de l'émission du certificat. (3 ans par exemple pour la validation EV, et 45 jours pour le certificats)


Certes. Mais cela signifie aussi plus de manipulation du certificat, donc plus de risque qu'il fuite. Je ne suis pas certains que cela soit souhaitable. Il faudrait avoir un retour sur la balance bénéfice/risque.
Pour info, Firefox n'ignore plus les certificats systèmes aujourd'hui.

Bien vu, merci ! J'étais resté avec mes vieux acquis.. :)

C'est même un peu plus subtile que ca :
https://mzl.la/3vVLmzx


Certes. Mais cela signifie aussi plus de manipulation du certificat, donc plus de risque qu'il fuite. Je ne suis pas certains que cela soit souhaitable. Il faudrait avoir un retour sur la balance bénéfice/risque.

Le certificat est une info publique, la clé privée ne sort jamais du système qui est à l'origine de la demande. :)
Mais oui, 45 jours parais court malgré tout.

XSBen

Pour info, Firefox n'ignore plus les certificats systèmes aujourd'hui.

Bien vu, merci ! J'étais resté avec mes vieux acquis.. :)

C'est même un peu plus subtile que ca :
https://mzl.la/3vVLmzx


Certes. Mais cela signifie aussi plus de manipulation du certificat, donc plus de risque qu'il fuite. Je ne suis pas certains que cela soit souhaitable. Il faudrait avoir un retour sur la balance bénéfice/risque.

Le certificat est une info publique, la clé privée ne sort jamais du système qui est à l'origine de la demande. :)
Mais oui, 45 jours parais court malgré tout.
Le certificat est une info publique, la clé privée ne sort jamais du système qui est à l'origine de la demande. :)


Pardon de mon imprécision : quand je parlais certificat, je voulais bien sûr dire certificat + clé privé ;) Les deux sont nécessaires au niveau du serveur applicatif (Apache, Nginx, etc.)

Mais Apple la déjà fait.
Depuis quelque années il ne valide plus les certificats passé leur premier années.
Donc si tu gère un site ba tu prend plus que des certificat valide 1 an, sinon ton site ne fonctionnera plus correctement sur les produit Apple.

Voila comment il force.

ben51

Mais Apple la déjà fait.
Depuis quelque années il ne valide plus les certificats passé leur premier années.
Donc si tu gère un site ba tu prend plus que des certificat valide 1 an, sinon ton site ne fonctionnera plus correctement sur les produit Apple.

Voila comment il force.
Alors, j'ai creusé, et effectivement, c'est bien le cas pour les autorités de certifications "publiques". On retrouve le même comportement pour Chrome et Safari.

Par contre, pour les autorités de certification internes, ce délai d'un an n'existe pas. Il y en a un autre qui est de 825 jours.

Et ce délai ne s'applique que pour les certificats "finaux", c'est-à-dire présentés par les sites pour la sécurisation. Les certificats intermédiaire ne semblent pas impactés.

Donc merci pour l'info, car j'étais passé complètement à côté.
J'ai du mal à voir comment Apple pourrait forcer


Si ils arrivent à faire adopter leur proposition par le "CA/Browser Forum", alors tous les émetteurs de certificats seront obligé de s'y contraindre, sous peine d'être éjectés des listes d'autorités de certification validées des différents systèmes (navigateurs, OS).
La cata pour les projets type Arduino!
Pour rappel la compression Brotli n'est possible qu'en https. Largement compensée par le chiffrement minimal ECC.
C'est complètement ignorer la réalité des usages. J'ai vu passer des projets de plateformes de services où la quantité de certificats manipulés dépassait allègrement la centaine malgré l'usage de SAN pour rationaliser le plus possible. Le tout sur des infrastructures différentes dont certaines gérant très mal l'automatisation. Et on est déjà sur des expirations d'un an que ce soit pour les publics ou privés.

Sans oublier les certificats machines, les protocoles à double certification (un pour la couche communication, un pour l'authent mutuelle entre les partenaires et le chiffrement de la donnée) type AS2 très utilisé dans le retail pour l'EDI, etc.

Déjà qu'on se bat pour que les produits désactivent l'option "ne pas vérifier les certificats" à cause des expirés pas renouvelés, de l'auto signé installé par Jean Michel il y a 8 ans mais que personne sait à quoi ça sert touche-surtout-pas-ça-marche, ou de ceux délivrés par une autorité interne mais qu'on est toujours infoutus d'avoir la CA déployée (ou ignorée parce que fucking key store Java et j'en passe).

Bref, à part vouloir donner du taff à des admins système et faire recruter dans le domaine, je vois pas la finalité. Le renouvellement de certifs en entreprise n'est pas aussi simple qu'un let's encrypt sur un nginx en auto.
Perso, j'utilise un certificat Let’s Encrypt et je ne peux pas automatiser son renouvèlement (à cause du HSTS) et c'est très casse-pieds.

Donc, je comprends tout à fait ceux qui doivent en gérer pleins…
Modifié le 21/10/2024 à 11h24

Historique des modifications :

Posté le 21/10/2024 à 11h19


Perso, j'utilise un certificat Let’s Encrypt et je ne peux pas automatiser son renouvèlement (à cause du HSTS) et c'est très casse-pieds.

Donc, je comprends tout à fait ceux qui doivent en gérer pleins…

En quoi HSTS te gêne pour l'automatisation ? Pour le challenge "well-know" en http ?
Tu ne peux pas utiliser le challenge DNS ?

fanto30

En quoi HSTS te gêne pour l'automatisation ? Pour le challenge "well-know" en http ?
Tu ne peux pas utiliser le challenge DNS ?
Ou le challenge TLS-ALPN-01 qui est similaire à http, sans nécessiter d'ouvrir le port 80

Oliverpool

Ou le challenge TLS-ALPN-01 qui est similaire à http, sans nécessiter d'ouvrir le port 80
Ouais, mais en même temps :
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon. Like HTTP-01, if you have multiple servers they need to all answer with the same content. This method cannot be used to validate wildcard domains.


C'est pas vraiment fait pour de l'automatisation "simple".

fanto30

En quoi HSTS te gêne pour l'automatisation ? Pour le challenge "well-know" en http ?
Tu ne peux pas utiliser le challenge DNS ?
Oui.
Je regarderais, mais je ne crois pas que le gestionnaire de certificat du DSM synology me laisse le choix sur la méthode…

Mihashi

Oui.
Je regarderais, mais je ne crois pas que le gestionnaire de certificat du DSM synology me laisse le choix sur la méthode…
De mon expérience avec l'outil certificats de DSM, t'as pas trop le choix de la procédure. Tu choisis Let's encrypt, tu mets le domaine + le mail et basta. C'est pour ça que j'ai arrêté cette partie et préféré remettre un frontal Nginx (avec WAF, au passage).

Les outils intégrés du syno sont trop limités, je trouve ça dommage.

fanto30

En quoi HSTS te gêne pour l'automatisation ? Pour le challenge "well-know" en http ?
Tu ne peux pas utiliser le challenge DNS ?
Tu peux automatiser le challenge DNS ?

Edit: Je viens de voir sur la doc, effectivement pas mal.
Modifié le 21/10/2024 à 13h43

Historique des modifications :

Posté le 21/10/2024 à 13h38


Tu peux automatiser le challenge DNS ?

Edit: Je viens de voir sur la doc, effectivement pas mal.

aureus

Tu peux automatiser le challenge DNS ?

Edit: Je viens de voir sur la doc, effectivement pas mal.
Tu peux automatiser le challenge DNS ?


Cela va dépendre du registrar. Si tu as une API dispo oui.
Le problème de fond, c'est comment éviter qu'un certificat compromis soit utilisé trop longtemps, une fois la compromission constatée.

Je connais 3 stratégies:
- réduction de la durée de validité du certificat
- listes de révocations: Certificate Revocation Lists (CRLs)
- Online Certificate Status Protocol (OCSP)

L'avantage de la réduction de la durée de validité du certificat, c'est qu'elle ne nécessite pas de mise à jour chez les clients. Seul le serveur doit renouveler plus souvent son certificat.

Les deux autres stratégies (OCSP & CRL) nécessitent des ajustements côté client (et serveur), gros soucis pour tous les IOTs et vieux appareils EOL.

J'avais eu quelques échanges à ce sujet à propos de https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/ sur lobste.rs: https://lobste.rs/s/k4uuth/intent_end_ocsp_service#c_cv0s36
Modifié le 21/10/2024 à 16h59

Historique des modifications :

Posté le 21/10/2024 à 11h53


Le problème de fond, c'est comment éviter qu'un certificat compromis soit utilisé trop longtemps, une fois la compromission constatée.

Je connais 3 stratégies:
- réduction de la durée de validité du certificat
- listes de révocations: Certificate Revocation Lists (CRLs)
- Online Certificate Status Protocol (OCSP)

L'avantage de la réduction de la durée de validité du certificat, c'est qu'elle ne nécessite pas de mise à jour chez les clients. Seul le serveur doit renouveler plus souvent sont certificat.

Les deux autres stratégies (OCSP & CRL) nécessitent des ajustements côté client (et serveur), gros soucis pour tous les IOTs et vieux appareils EOL.

J'avais eu quelques échanges à ce sujet à propos de https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/ sur lobste.rs: https://lobste.rs/s/k4uuth/intent_end_ocsp_service#c_cv0s36

Ça n'est pas vraiment un ajustement, dans la mesure où ces mécanismes de révocation existent depuis très longtemps, et que la révocation doit toujours être implémentée pour que le système soit sécurisé.

Réduire la durée de validité n'est pas une manière correcte pour se protéger contre des clés compromises.
C'est plutôt une protection additionnelle si l'attaquant réussi à déjouer les mécanismes de révocation ou à ne pas se faire repérer.
Je serais curieux de voir la démarche qui a mené au chiffre 45. Pourquoi pas 15 ou 60, mais 45.
C'est du à l'âge moyen des certificats compromis ? A la taille maximale de l'historique pour que les listes de révocation soient fera les, ou tout simplement le jet d'1D100 ?
Encourager à renouveler tous les mois, peut-être.
Pour Let’s Encrypt, il me semble que certaines des implémentations renouvellent tous les 60 jours au lieu de 90.
Ça laisse le temps de se retourner si l’automatisation foire (d’abord on attend quelques jours pour que ça réessaie tout seul puis on se penche sur le problème sans être dans l’urgence absolue).

Bien sûr, il faut vérifier les logs pour détecter les échecs mais c’est une des idées qui pourrait expliquer le choix.
Il faudrait déjà que google vérifie la révocation des certificats avant de vouloir réduire sa durée de vie.

Firefox le fait très bien.

Quand la sécurité devient absurde et génère une charge de travail supérieur sur les admins systèmes
Fermer